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Abstract. Automatic or assisted workflow composition is a field of in- 
tense research for applications to the world wide web or to business pro- 
cess modeling. Workflow composition is traditionally addressed in various 
ways, generally via theorem proving techniques. Recent research pQ ob- 
served that building a composite workflow bears strong relationships with 
finite model search, and that some workflow languages can be defined as 
constrained object metamodels |2I3| . This lead to consider the viability 
of applying configuration techniques to this problem, which was proven 
feasible. Constrained based configuration expects a constrained object 
model as input. The purpose of this document is to formally specify the 
constrained object model involved in ongoing experiments and research 
using the Z specification language, and more precisely using some of the 
definitions in 

1 Introduction 

We place ourselves in the scope of automatic or computer aided workflow com- 
position, with immediate applications to Business Process Modeling or the Se- 
mantic Web. The basic assumptions for composing workflows is that there exists 
a form of directory listing of elementary workflows that are potential candidates 
for composition, as well as a directory listing of transformations that are us- 
able to mediate between workflows having "bitwise" incompatible message type 
requirements. How and when a proper list of elementary workflows and trans- 
formations can be obtained is beyond the scope of this research, and is treated 
as if it was available to the program from the start. 

We also assume that the composition process is goal oriented: a user may list 
the message types he can possibly input to the system (e.g. credit card number, 
expiry date, budget, yes/no answer etc.), and the same user may formulate the 
precise (set of) message(s) that must be output by the system (e.g. a plane ticket 
reservation electronic confirmation: the "goal"). 

A previous work proved the feasibility of using a configurator program to 
solve this problem, and presented a constrained object model adequate for this 
purpose, using the semi formal language UML/OCL. Although it was shown in 
|3] that such a use of UML/OCL is viable, the language is also known as having 
limitations, notably concerning relational operators. The original contribution 
of this work is to propose a formal specification of the same constrained object 



model using the Z specification language. Z was shown suitable for such a usage 
in 0|, via a framework for the Z specification of constrained object models 3 . 
This research heads towards the complete formal specification of a constrained 
object model for workflow composition. 

The plan of the article is as follows. The current section is introductory, 
and briefly presents the context retained for dealing with workflow composition 
configuration in Subsection 11.11 a brief introduction to configuration in Sub- 
section^^ how composition can be treated as a configuration task in Section 
11.31 and related work in 11.41 Section [21 briefly introduces Z and the predefined 
class construct used in the specification. Section |31 presents the specification of 
a constrained object model combining a metamodel for activities and data type 
ontologies. Section 0] concludes and presents research perspectives. 

1.1 Context for workflow composition 

We consider workflows defined using a variant of extended workflow nets, as 
are UML2 activity diagrams [2] or the YAWL language 3 . The underlying 
model is that of colored Petri nets, where messages (tokens) have types. We 
do not consider however the underlying semantics of the workflow language, 
but focus on the properties of the corresponding metamodel. Indeed, we treat 
workflow composition as the process of connecting input and output message 
flows to preexisting or added workflow items, like fork, join nodes or auxiliary 
user input handling actions. Hence the only element retained for composition are 
the structural properties of argument workflows, messages, and transformations. 
We do not need to emulate workflows in any case, but can however formulate 
some constraints that to some extent guarantee the viability of the result. 

The same general context is envisioned in several research communications 
|6I7I8| . We illustrate 1 our central assumptions by considering the rather complex 
Producer/Shipper composition problem from [jy. The problem is to compose a 
valid workflow from a producer workflow and a shipper workflow. One difficulty is 
that the execution of both workflows must be interleaved. The producer outputs 
results that must be fed into the shipper so that both " offers" can be aggregated 
and presented to the user. This inter-connection remains unknown to the user. 
This example is interesting because: 

— both the shipper and the producer make an offer corresponding to the user 
request, which are aggregated to make a global offer which can be accepted 
or rejected by the user. Note that the shipper needs input data from the 
producer to build its offer, 

— both the producer and the shipper are specified using partial workflows, and 
do not simply amount to simple isolated activities, 

— the two partial workflows cannot be executed one after the other, but they 
must be interleaved, as each one must wait for the other offer to obtain an 
OfferAcceptance and therefore complete the transaction, 

3 Also called Object Oriented Constraint Programs 



— the Shipper Workflow needs a size as input, which can only be obtained by 
extraction (i.e transformation) on the ProducerOffer, 

— finally, the goal is decomposed into two sub- goals: the producer and the 
shipper order confirmations. 
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Fig. 1. The shipper provided workflow 



Figure ^ illustrates the shipper's partial workflow, as defined before search 
begins. The producer's workflow is similar, modulo the message type ontologies. 

The composition result is shown in Figure^ This composed workflow involves 
synchronization, interleaving, transformations (we used oval boxes to denote 
transformations) and it should be noted that some execution paths are discarded: 
indeed, under user rejection, the goal cannot be fulfilled. This illustrates why we 
later will need a Boolean attribute for active paths in the metamodel. 

Basically, the external user is present via the message it inputs to the global 
workflow. In Figure|3 all the workflow elements that are not visible in the shipper 
workflow above or its producer counterpart must be introduced automatically 
in order to obtain a valid composition. 

1.2 Brief introduction to configuration 

A configuration task consists in building (a simulation of) a complex product from 
components picked from a catalog of types. Neither the number nor the actual 




types of the required components are known beforehand. Components are subject 
to relations, and their types are subject to inheritance. Constraints (also called 
well-formedness rules) gencrically define all the valid products. A configurator 
expects as input a fragment of a target object structure, and expands it to a 
solution of the configuration problem, if any. This problem is semi-decidable in 
the general case. 

A configuration program is well described using a constrained object model 
in the form of a standard class diagram (as illustrated by Figures 0}, to- 
gether with well-formedness rules or constraints (also called the semantics in the 
UML/OCL framework). Technically solving the associated enumeration prob- 
lem can be made using various formalisms or technical approaches: extensions 
of the CSP paradigm |9I1U| . knowledge based approaches ^J, terminological 
logics |12) . logic programming (using forward or backward chaining, and non 
standard semantics) object-oriented approaches |14lll| . Our experiments 
were conducted using the object-oriented configurator Hog J Configurator [T3| . 



There currently exists no universally accepted language for specifying con- 
strained object models. The choice of UML/OCL is advocated [S], and is realistic 
in many situations, but has some drawbacks due to a number of limitations in 
the OCL language, as for instance the lack of a relational cross product operator. 
As shown in 0] the Z relational language has enough expressive power and ex- 
tensibility to properly address the task of specifying a constrained object model, 
without requiring to use an ad hoc object oriented extension of Z. 
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Fig. 3. Meta-model for workflows activities 



UML diagrams mention some of the model constraints, most notably relation 
cardinalities, as e.g. that a message relates to at most one Activity in Figure 
but there is no possibility to graphically cover the whole range of constraints 
that may occur in an object model. 

1.3 From configuration to workflow composition 

Configuration emerges as an AI technique with applications in many different 
areas, where the problem can be formulated as the production of a finite in- 
stance of an object model subject to constraints. Reasoning about workflows 
falls into this category, because a workflow description is an instance of a given 
metamodel (as is the UML metamodel for activity diagrams 2 ). Composing 
workflows is a configuration problem in that in so doing, one must introduce an 
arbitrary number of previously non existent transitions (fork, join, split, merge, 
transformations, pre-defined user- interactions sequences), and interconnect in- 
put and output message pins provided they have compatible types. The user of 
a workflow composition system in our sense provides: 



— a list of potentially usable workflows, implemented in the form of partially 
defined instances of the workflow metamodel used, (e.g. a producer for some 
good, a shipper, a payment service, etc.) 

— the ontologies for the data types linked to the input /output messages present 
in the workflows (e.g. types of journeys: by train, plane, etc. , methods of 
payment: cheque, credit card, cash etc.) 

— a goal to be satisfied by the result composition (e.g. a train ticket reserva- 
tion), 

— a list of the data input he can provide (e.g. simple "yes/no" answers, credit 
card number, expiry date, selected item etc.) 

In our approach the goal is defined as the type in an appropriate ontology of 
a message connected to the final node of the composite workflow. The inputs 
provided by the user are modeled as external signals. 

The user of a workflow composition system expects in return for his input 
a complete " composite" workflow, that interleaves the execution of several of 
the elementary argument workflows, while ensuring that all possible integrity 
constraints remain valid. Among such constraints are those that stem from the 
metamodel itself: for instance some constraints state that two or more workflows 
should not be inter-blocking, all waiting for some other to send a message. Other 
constraints are more problem specific, like those stating for instance that an item 
being shipped is indeed the one that was produced. 

1.4 Related work 

Automated workflow composition is a field of intense activity, with applications 
to at least two wide areas: Business Process Modeling and the (Semantic) Web 
Services. Tentative techniques to address this problem are experimented using 
many formalisms and techniques, among which Situation calculus |15| . Logic 
programming 16 , Type matching: J7|, Coloured Petri nets: |6I7| . Linear logic: 
ITS]. Process solving methods |19I2UI2I| . AI Planning Hierarchical Task 
Network (HTN) planning |Z5I24| . Markov decision processes |25| . 

2 Introducing Z 

(Note to the reviewer: this section is provided in order to improve the self-containness 
of the article, and if accepted can be removed from a final version, or moved to an 
annex, depending upon how tight the page limit is. All relevant references are freely 
electronically available.) 

For space reasons, it is impossible to make this paper self contained, since this 
would suppose a thorough presentation of both the UML notation 0, and the 
Z specification language |2fi| . The reader, if novice in these domains, is kindly 
expected to make his way through the documentation, which is electronically 
available. For clarity however, we provide a brief description of several useful 
Z constructs. More advanced notations or concepts will be introduced when 
necessary. 



2.1 data types as named sets 

Z data types are possibly infinite sets, either uninterpreted (DATE), or axiomat- 
ically denned as finite sets (dom), or declared as explicitly initialized free types 
(colors: : 

[DATE] 

j dom : F N 

colors ::= red \ green \ blue 

From now on, all possible relation types can be built from cross products of 
other sets. 

2.2 axiomatic definitions 

Axiomatic definitions allow to define global symbols having plain or relation 
types. For instance, a finite group is declared as 

zero : dom 

inverse : dom — > dom 
sum : dom x dom — > dom 

V x : dom • sum(x, inverse(x)) — zero 

V x : dom • sum(x, zero) = x 

M x, y : dom • sum(x, y) = sum(y 1 x) 

V x,y,z : dom • sum(x, sum(y, z)) = sum(sum(x, y), z) 

The previous axiomatic definition illustrates cross products and function defini- 
tions as means of typing Z elements. Now axioms or theorems are expressed in 
classical math style, involving previously defined sets. For instance, we may for- 
mulate that the inverse function above is bijective (this is a theorem) in several 
equivalent ways as e.g.: 

inverse G dom >— » dom 

where the >— » operator defines a bijection, or explicitly using an appropriate 
axiom : 

V y : dom •3 1 x : dom • inverse(x) = y 

2.3 schemas 

The most important Z construct, schemas, occur in the specification in the 
form of named axiomatic definitions. A schema [D \ P] combines one or several 
variable declarations (in the declaration part D) together with a predicate P 
stating validity conditions (or constraints) that apply to the declared variables. 



SchemaOne 

a : N 

b : 1 . . 10 

b < a 



The schema name hides the inner declarations, which are not global. A schema 
name (as SchemaOne above) is used as a shortcut for its variable and predicate 
declarations that can be universally or existentially quantified at will. Schemas 
are true or false under a given binding. For instance, SchemaOne is true under 
the binding (4 ^ a, 3 ^- b) and false under the bindings (3 ^ a, 234 ^ b) or 
(3 a, 4 ^- b). The latter violates the explicit constraint stated in the predicate 
part of the schema, while the former also violates the implicit constraint carried 
by the interval definition 1 . . 10 (a subset of N). In some contexts, a schema name 
denotes the set of bindings under which it is true. 

Z allows Boolean schema composition. Two schemas can be logically com- 
bined (e.g. "anded") by merging their declaration parts provided no conflict 
arises between the types of similarly called variables, and by applying the corre- 
sponding logical operator (e.g. the conjunction) to the predicates. For instance, 
given the schema SchemaOne above, and another schema called SchemaTwo = 
[&:N;c:N|fe<c] 4 , we may form the schema SchemaThree: 

SchemaThree = SchemaOne A SchemaTwo 

Incidentally, the variable declarations b in both schemas collide, but not for their 
types since & is a member of N in both cases. The first declaration of b bears a 
built in constraint, which can be moved to the predicate part. Hence the schema 
SchemaThree would list as : 

SchemaThree 

a, &, c : N 

1< b < 10 
b < a 
b < c 



2.4 shortcut notation for class specifications 

Z being non object oriented in any way, the specification of an object system 
is verbose. In 0] are proposed the following shortcut definition for classes and 
types, which makes use of the keywords class, abstract, discriminator, inherit. 
We illustrate here the general framework using a simple three class example. 
Assume that A,B,C are the sole classes in a constrained object system where 
B and C inherit A. The Z "extension" from 4 allows for the following simple 
declarations: 



4 This illustrates another syntax for simple schema declarations 



class — A : abstract 

— discriminators : default 
a : N 

a < 10; 



class — B : concrete 

— inherit : A — default 
b : Mi 



class — C : concrete 

— inherit : A 

a > 5; 



These class declarations are a shortcut for the declaration in the Z specifi- 
cation of diverse sets and axiomatic definitions, of the schemas : ObjectDef, 
ClassDefA, ClassSpecA, ClassDefB, . . ., and of the sets instances (Class A), A, 
instances (ClassB), . . ., with: 

[ ObjectReference] 

ReferenceSet == ¥ ObjectReference 

Object references are central to the object system, since they allow for specifying 
object identity. We have three class names: 

CLASSNAME ::= ClassA \ ClassB \ ClassC 
The function instances maps class names to sets of object references: 

! instances : CLASSNAME — > ReferenceSet 

The ObjectDef schema introduces a part common to all object representations: 

ObjectDef 

ref : ObjectReference 
class : CLASSNAME 



Now, the ClassDef'X' schemas introduce the part specific to each class, plus 
inheritance using schema inclusion 



ClassDefA 
a: 1..10 



ClassDefB 
ClassDefA 
b : Ni 



ClassDefC 
ClassDefA 

a > 5 



Class specifications introduce the common ObjectDef part and constrain the 
class attribute to its proper value: 

ClassSpecA = ClassDefA A [ObjectDef | class — Class A] 
ClassSpecB = ClassDefB A [ObjectDef | class = ClassB] 
ClassSpecC = ClassDefC A [ObjectDef \ class = ClassC] 

Then finally the object system can be modelled, by introducing the sets A, B, C 
of references that correspond to the usual undestanding of object "types" , again 
accounting for inheritance: 

A, B, C : References et 



A = instances (Class A) UBUC 
B = instances(ClassB) 
C = instances (ClassC) 

instances (Class A) = {o : ClassSpecA \ o. class = Class A • o.i} 
instances (ClassB) = {o : ClassSpecB | o. class = ClassB • o.i} 
instances (ClassC) = {o : ClassSpecC | o. class = ClassC • o.i} 

Mi : instances(ClassA) • (3 1 x : ClassSpecA • x.ref = i) 
Vi : instances (ClassB) • (3 ± x : ClassSpecB • x.ref = i) 
Vi : instances (ClassC) • (3 l x : ClassSpecC • x.ref = i) 

The sequel of the presentation makes use of the "class" shortcuts introduced 
above, and of some of the role dereferencing operators — >, — ^ •, ~* : 

F W 

_ — > _ : F ObjectReference x (ObjectReference — > X) — > bagX 
_ — 1 _ : F ObjectReference x (ObjectReference — > X) — > X 
_ • _ : F ObjectReference x (F ObjectReference — >FI) — >F X 
_ _ : ObjectReference x (F ObjectReference — > F X) — >F X 



Vs : F ObjectReference; r : ObjectReference — > X • s — > r = bagOf (r)(s) 
Vs : F ObjectReference; r : ObjectReference — > X • 

s r = (fit : bagOf (r)(s) • first t) 
Ms : F ObjectReference; r : F ObjectReference — > F X • s ■ r — r(s) 
V o : ObjectReference; r : F ObjectReference — >FI«o«r = r ({°}) 



where the function bagOf maps every function from ObjectReference to X to a 
function from sets of ObjectReference to bags of X , assuming the existence of a 
function pickFirst applied to any set of (totally ordered) object references: 

bagOf : (ObjectReference — > X) — > (F ObjectReference — > bag X) 

V/ : ObjectReference — ► X • bagOf (f)(0) = [] 

V/ : ObjectReference — > X • 

\f d : F 1 (dom/) • (let x == pickFirst(d) • 
bagOf(f)(d) = (bagOf(f)(d \ {x}) W ({f(x) h+ 1}))) 



3 A metamodel for workflow composition 

Workflow reasoning requires a workflow language with enough generality to be 
practically viable. Furthermore in our case, since we expect to treat workflow 
composition as a configuration task, it is of particular importance that the lan- 
guage is modular wrt. most if not all the workflow patterns referenced in |27| . 
The simplest such language is the extended workflow net YAWL language [H], 
now a subset of UML2 activity dia grams. 

We present our constrained object model according to the standard model 
driven architecture recommendations, except for the use of the Z language as a 
formal specification language. The next subsection introduces the classes, and 
their associations and attributes using class diagrams. This presentation is then 
followed by a detailed presentation of the relevant constraints, in the form of Z 
axiomatic definitions. 

3.1 Metamodel specification 

Actions Actions are the core constituents of a workflow. As defined in UML2, 
actions may have a certain number of messages as their inputs and outputs. 
Those inputs/outputs have defined types, taken from existing ontologies of data 
types. All actions have an "owner" (the original workflow they belong to: for 
instance, an action may belong to the Producer workflow). In UML2 the term 
workflow is synonym to that of Activity. All workflow parts that are dynamically 
added by the configurator in order to create the composed workflow belong to 
a newly introduced owner called the Composition Workflow. There are different 
types of actions, illustrated in the metamodel in Figure 01 

— Initial nodes: the starting point of the workflow. Initial nodes don't take any 
inputs. They are graphically represented using a black circle. 

— Final nodes: a possible end of the workflow. Final nodes don't produce any 
outputs and are represented using a white circle and a black dot in the center. 
There may be several final nodes in a workflow. 



— Control nodes: joins, forks, merges, decisions. A fork initiates concurrency 
by duplicating its input token to all outputs. Join is the corresponding syn- 
chronization construct. Decision (also known as "split") and merge are the 
standard if/else conditional branching constructs. 

— Actions: activities which include a local action executed by the workflow 
owner. 

— Transformations: activities for transforming message data types with no fur- 
ther side effect. Transformations are called data mediators in the context 
of web service composition. Available transformations can be chosen by 
the composition designer, or they can be discovered (as e.g. in the con- 
text of Semantical Web Services). The distinction between actions in gen- 
eral and transformations in particular is widely acknowledged in the work- 
flow/process/ WS communities. Called "data mediators" in the context of 
WS, UML2 "transformations" have the sole effect of reformatting data, and 
do not enter in further interactions with other parts of the workflow. 

— External Signals: An activity that outputs external messages, typically user 
provided messages. 

Class specifications We now introduce the Z specification of the constrained 
object model used for the configuration of workflow compositions. The class 
specifications listed below straightforwardly follow from Figure We use the 
notational shortcuts introduced in 0] for class declarations. These shortcuts al- 
low for straightforward class definitions, and introduce several (hidden) auxiliary 
data types and sets. We also take the freedom of introducing the type "Boolean" 
in the language, for the sake of simplicity. 

Boolean ::= true \ false 

class — Activity : abstract 

active : Boolean 



class — Action : concrete 

— inherit : Activity 



class — ControlFlow : abstract 

— inherit : Activity 



class — ExternalSignal : concrete 

— inherit : Activity 



and similarly for InitialNode, FinalNode, Transformation. 

class — Decision : concrete 

— inherit : ControlFlow 



and similarly for Merge, Split, Join. 



class — Message : concrete 

active : Boolean 
order : N 

order > 



Relation specifications According to Figure 01 there exists a relation between 
workflows and abstract actions: each action has a single owner workflow. This 
can be modeled using an injection 

| owner : Activity > — > Workflow 

The relations listed in Figure 03 between the Activity and Message classes can 
be specified as: 

outputs : Activity <— > Message 
inputs : Activity <— > Message 
isOutputOf : Message H-> Activity 
isInputOf : Message H-s> Activity 

isOutputOf — outputs^ 
isInputOf = inputs^ 

where inputs^ denotes the relational inverse of the relation inputs, and h-> 
denotes a partial injection. Partial injections are useful to specify situations 
modeled using 0, f cardinalities as in Figure |3| 

3.2 Ontology of message types 

Each message has a related data type, from a workflow specific ontology. We use 
predefined ontologies for user interaction schemes, and import the ones required 
by the selected web services. User interaction schemes, as implemented by the 
composition activity Offer Acceptance, constrain the types of their I/O messages. 
From an abstract standpoint, they output an OfferAnswer if both an Offer and 
an User Acknowledgement are provided. However the precise Offer / OfferAnswer 
type match is constrained: they must share the same owner workflow. For exam- 
ple, a ShipperOfferAnswer can be output only if a ShipperOffer is input to the 
user interaction. Figure 21 illustrates the fact that such answers belong to both 
the hierarchy of standard datatypes and of imported service ontologies. 

Class specifications The class specifications straightforwardly follow from Fig- 
ure m 

Currency ::— Euro \ Dollar \ Yen . . . 



Message 

-active:Boolean 



ProducerOffer 

-productSizeiint 



Fig. 4. Abstract model for workflow data types ontologies 
class — DataType : abstract 



class — Offer : abstract 

— inherit : DataType 
price : N 

currency : Currency 



class — Offer Answer : abstract 

— inherit : DataType 
accepted : Boolean 



class — User Acknowledgement : concrete 

— inherit : DataType 



class — ProducerOffer : concrete 

— inherit : Offer 
size : N 



class — ProducerOffer Answer : concrete 

— inherit : Offer Answer 



class — ShipperOffer : concrete 

— inherit : Offer 
deliveryDays : N 



class — ShipperOffer Answer : concrete 

— inherit : Offer Answer 



_^ DataType 

4r 
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-Currency:String 
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ShipperOffer Answer 



Relations There is a relation between the Message and DataType class, whereby 
each Message binds to at most one DataType object. This is specified using a 
partial function. The same DataType instance might be shared across several 
Messages, hence the function dataType is not injective 

j dataType : Message -B> DataType 
3.3 Semantics 

The previous object models are not enough to describe valid compositions, and 
require a number of constraints governing the possible combinations of partial 
workflows and additional elements that form acceptable compositions. We spec- 
ify here a limited number of these constraints that are representative enough to 
grasp the general idea. 

Composition specific constraints From the simplified and slightly adapted 
subset of the UML2 activity diagram metamodel in Figure |3 we observe that 
both the Activity and Message classes implement a Boolean attribute called 
"active". This Boolean helps ensuring that a workflow can be composed from 
sub-workflows if and only if at least one valid path yields the expected goal. This 
allows our tool to produce composite workflows under the additional constraint 
that control flow constructs must match the following constraints applying to 
activities and messages: 

— if an action is active, then all its input messages are active, 

— if an active message is output of a join, then all inputs of the join must be 
active, 

— if an active message is output of a decision or a fork, then the input of this 
activity must be active, 

— if an active message is output of a merge, at least one of this merge's inputs 
must be active. 

According with these, the program builds solutions such that at least one path 
leads from the initial node to a final node reached via a message having the 
correct goal type. In the case a valid path traverses a fork or a join, all other 
incoming/outgoing paths must be valid too. If a user wants a robust solution 
(meaning that all branches are valid), this can be obtained by forcing all parts 
of the workflow to be active. 

Activation related constraints These constraints are not problem-specific 
and therefore apply to any composition. The Boolean "active" denotes which 
part of a workflow indeed participate in the solution. The rationale for this is as 
follows: a workflow argument to a composition may involve decision/merge paths 
that are ignored because either the conditions for their activation are known as 
impossible (e.g. because from the connected message, we know that a test will 
always fail) or because an exterior message required for their successful execution 



is known as missing (e.g. a user message giving a credit card number in case the 
user has none). 

"If an action is active, then all of its inputs must be active messages" : 

Va : Action • a. active => V m G inputs(a) • m. active 

"If an active message is output of a join, then all inputs of the join must be 
active" : 

Vm : Message | m. active A m ~-> isOutputOf G Join • 

Mm' : Message m' £ in « isOutputOf ~» inputs • m'. active 

"If an active message is output of a decision or a fork, then all inputs of this 
activity must be active" : 

Vm : Message | ra. active A m isOutputOf G Decision U Fork • 
Vm' : Message m' £ in « isOutputOf ~-> inputs • m'. active 

"If an active message is output of a merge, at least one of this merge's inputs 
must be active" : 

Vm : Message | m. active Am ^ isOutputOf G Merge • 

3 m' : Message m' 6 in « isOutputOf ~-> inputs • m 1 .active 

"If a merge is active, then at least one of its inputs must be an active message" : 

V a : Merge • a. active => 3 m G inputs (a) • m. active 

Composition related constraints We assume the existence of a specific work- 
flow instance called "Composition" : 

! Composition : Workflow 

"All messages input of an external workflow are output of the composition work- 
flow": 

V m : Message • m isInputOf ^> owner =/= Composition => 

m ~~> isOutputOf owner = Composition 

and conversely "All messages output of an external workflow are input of the 
composition workflow" : 

Vm : Message • m isOutputOf ^ owner ^ Composition => 
m ^ isInputOf ^> owner = Composition 

Message ordering related constraints Our model implements an integer 
"order" parameter in the Message class that is used to prevent building inter- 
locking or looping constructs. 

"the order of an action's input message is lower than the action's output messages 
orders (this "ordering" constraint allows to prevent looping situations in the 
composite workflow): 

V m : Message •Mm': Message \ 

m' G m ^> isInputOf outputs • m. order < m'. order 



Pre-defined composition constraints An OfferAcceptance action expects as 
input an Offer plus a User Acknowledgement, and produces an Offer Answer as 
a result. Both the Offer and the Offer Answer point to actions having the same 
workflow owner, which is not the Composition workflow. 

V o : Offer, a : Offer Answer \ o ~^ isInputOf = a ~* outputOf • 

isOutputOf ~* owner = a isInputOf ~+ owner 

Also, Fork nodes have the same type for their inputs and outputs. Formulating 
such a constraint is possible, under the assumptions in 0] 

V/ : Fork, i, o : Message \ i ■>*» isInputOf — o ^ isOutputOf = f • 

1 — * getClass = o getClass 

Problem specific constraints User provided message types fall into a few 
categories, as e.g. credit card information, age, or budget... Assuming the user 
input message type classes Userlnputf, Userlnput2, ... 

Vm : Message \ m isOutputOf £ ExternalSignal • 
m —* getClass £ Userlnputl, Userlnput2, . . . 

Also, a concrete composition instance must list the available transformation 
types. In the context of (semantic) web service discovery, such transformations 
may be the result of a query to a repository of ontology mediators. 
Finally, a precise workflow composition problem instance may involve policy 
related constraints: constraints that are required to filter out valid yet unwanted 
compositions, for instance in a way such that offer's prices fall below a given 
maximum value. 

4 Conclusion 

This work proposes a formal specification using the Z language of a constrained 
object model involved in automatic workflow composition. Constrained object 
models can be exploited straightforwardly by configurators to achieve automatic 
or assisted workflow composition. Our formalization abstracts from the technol- 
ogy used to assess the validity of such an approach, so that different configuration 
techniques can be tested or compared on the same problem. 

Configuration expects a constrained object model to operate, hence puts the 
application design in a field familiar to many engineers. An essential part of the 
object model, the metamodel for activity diagrams, already exists as a (subset 
of) part of the UML2 specification relative to activity diagrams. Our Z specifi- 
cation is compatible with all UML2 class diagram features (including multiple 
inheritance and inheritance discriminators) , thus allowing for the straightforward 
translation of class diagrams. The advantages of Z wrt. UML/OCL are in the 
statement of constraints. For instance UML dramatically lacks relational con- 
structs and a cross product operator. Since in configuration problems, relations 



abound with extra semantics (injectivity etc.), object model constraints can be 
freely stated in Z, also taking advantage of using the richness of Z relational 
operators, and the ability to define additional operators. 
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